Aller au contenu principal

Critères qualité d’une exigence/user story

Ce document compile les critères de qualité pour les exigences et user stories, issus de différentes sources : BABOK, norme IEEE 830, IREB et le mnémonique INVEST pour les projets Agile.

BABOK​

  • Atomique : Autonome et capable d’être compris indépendamment d’autres exigences ou conceptions.
  • Complet : Suffisant pour guider les travaux ultérieurs et au niveau de détail approprié pour que les travaux puissent se poursuivre.
  • Cohérent : Aligné sur les besoins identifiés des parties prenantes et non incompatible avec d’autres exigences.
  • Concis : Ne contient aucun contenu superflu et inutile.
  • Réalisable : Raisonnable et possible dans le cadre du risque, du calendrier et du budget convenus, ou considéré comme suffisamment réalisable pour permettre une enquête plus approfondie au moyen d'expériences ou de prototypes.
  • Non ambigu : Le besoin doit être clairement énoncé de manière à faire apparaître clairement si une solution répond ou non au besoin associé.
  • Testable : Capable de vérifier que l'exigence ou la conception a été satisfaite. Les niveaux acceptables de vérification du respect dépendent du niveau d’abstraction de l’exigence ou de la conception.
  • Priorisé : Classé, regroupé ou négocié en termes d'importance et de valeur par rapport à toutes les autres exigences.
  • Compréhensible : Représenté en utilisant la terminologie courante du public.

Norme IEEE 830​

  • Correct : La spécification doit refléter fidèlement les besoins réels des utilisateurs et du système, sans erreur ni omission. Elle doit être conforme aux attentes et aux exigences définies.
  • Non ambigu : Le besoin doit être clairement énoncé de manière à faire apparaître clairement si une solution répond ou non au besoin associé.
  • Complet : Suffisant pour guider les travaux ultérieurs et au niveau de détail approprié pour que les travaux puissent se poursuivre.
  • Cohérent : Aligné sur les besoins identifiés des parties prenantes et non incompatible avec d’autres exigences.
  • Classé en fonction de son importance et/ou de sa stabilité : Classé, regroupé ou négocié en termes d'importance et de valeur par rapport à toutes les autres exigences.
  • Vérifiable : Capable de vérifier que l'exigence ou la conception a été satisfaite. Les niveaux acceptables de vérification du respect dépendent du niveau d’abstraction de l’exigence ou de la conception.
  • Modifiable : La spécification doit pouvoir être modifiée facilement en réponse à l'évolution des besoins ou à des corrections, tout en maintenant sa cohérence et sa traçabilité.
  • Traçable : Il doit être possible de suivre chaque exigence tout au long du cycle de vie du projet, depuis sa définition jusqu'à sa mise en œuvre et sa validation, permettant une gestion efficace des changements et une vérification de leur conformité.

IREB​

  • Adéquate : Décrit les besoins réels et convenus des parties prenantes. Les exigences doivent être pertinentes et appropriées par rapport aux objectifs du projet, répondant aux besoins des parties prenantes sans inclure d'informations superflues.
  • Nécessaire : Chaque exigence doit être essentielle pour atteindre les objectifs du projet ou du système, sans inclure d'éléments redondants ou non indispensables.
  • Non-ambiguë : Le besoin doit être clairement énoncé de manière à faire apparaître clairement si une solution répond ou non au besoin associé.
  • Complète (autonome) : Suffisant pour guider les travaux ultérieurs et au niveau de détail approprié pour que les travaux puissent se poursuivre et capable d’être compris indépendamment d’autres exigences ou conceptions.
  • Compréhensible : Représenté en utilisant la terminologie courante du public.
  • Vérifiable : Capable de vérifier que l'exigence ou la conception a été satisfaite. Les niveaux acceptables de vérification du respect dépendent du niveau d’abstraction de l’exigence ou de la conception.

Mnémonique INVEST pour les projets de développement logiciel Agile de Bill Wake​

  • Indépendante : La user story doit pouvoir être développée et livrée indépendamment des autres stories, afin de faciliter la planification, la priorisation et la livraison incrémentale.
  • Négociable : La story doit rester flexible et ouverte à la discussion. Elle n’est pas un contrat rigide, permettant aux équipes de collaborer pour définir la meilleure solution.
  • Valeur utilisateur : La story doit apporter une valeur claire et tangible à l’utilisateur ou au client, justifiant ainsi son développement.
  • Estimable : La story doit être suffisamment claire pour permettre à l’équipe d’estimer le temps ou l’effort nécessaire à sa réalisation.
  • Small : La story doit être de taille raisonnable, facilement réalisable dans un court cycle de développement (généralement une itération ou sprint), pour assurer une livraison rapide et une meilleure gestion.
  • Testable : La story doit pouvoir être vérifiée par des tests, afin de confirmer qu’elle a été correctement implémentée et qu’elle répond aux critères d’acceptation.# Markdown syntax guide